跟客戶談備份需求，十次有九次會被問到：「你們的RPO、RTO是多少？」

這兩個縮寫幾乎是備份領域的通用語言，但我發現不少人其實只是背下了英文全名，沒有真正想過這兩個數字對自己的企業代表什麼。這篇想用最白話的方式，把這兩件事講清楚。

RPO：你能接受「弄丟多少時間」的資料

RPO（Recovery Point Objective，復原點目標）回答的問題是：

如果現在系統掛了，我最多能接受回到多久以前的資料？

舉個例子：如果備份是每天凌晨2點做一次，系統在下午3點掛掉，代表你會弄丟從凌晨2點到下午3點之間、這13個小時的所有資料異動。這13個小時，就是這套系統實際的RPO。

RPO越短，代表能接受的資料損失越少，但相對地，備份就要做得越頻繁，成本也越高。所以RPO從來不是「技術問題」，而是企業願意付多少成本，換取多少資料損失風險的取捨。

不同系統，RPO要求本來就不一樣：

• 核心交易系統（例如銀行的存款交易）：可能要求RPO幾乎為零
• 一般辦公文件、內部系統：RPO一天甚至更長，通常都能接受

RTO：你能忍受「停機多久」

RTO（Recovery Time Objective，復原時間目標）回答的是另一個問題：

系統掛了之後，我最多能忍受多久沒辦法用？

如果一套系統的RTO是4小時，代表從出事的那一刻起，企業預期4小時內要把系統重新救回來、恢復正常運作。超過這個時間，對業務造成的衝擊，就是企業要認真面對的風險。

RTO同樣沒有標準答案，關鍵在於這套系統停下來，一小時損失多少？

• 對外的線上交易系統，停機一小時可能就是實質營收損失，加上信譽受損
• 內部行政系統，停個半天，頂多是不方便，還不至於傷筋動骨

這兩個數字，決定了架構怎麼設計

RPO跟RTO看似只是兩個數字，但實際上它們反推回去，直接決定了備份架構該怎麼蓋：

我在專案上最常遇到的狀況，是客戶一開口就說「我們什麼系統都要RPO趨近於零、RTO越快越好」。聽起來很合理，但落到預算跟架構上，往往超出實際需求跟成本負擔。比較務實的做法，是先把系統分級——哪些是真正核心、不能停的，哪些其實可以接受多一點緩衝，再依照分級去配置對應的備份跟復原架構。

這兩個數字，該問誰？

RPO、RTO常被丟給IT部門自己訂，但其實這是業務單位該回答的問題，IT負責的是「用什麼架構去達成」。IT人員可以幫忙換算成本、評估可行性，但「能不能接受停機4小時」這種問題，答案應該來自真正承擔業務風險的人。

下一篇想聊聊備份到底該放哪裡才安全，從經典的3-2-1原則，講到現在企業實際上怎麼做。

你們公司的核心系統，RPO、RTO是怎麼定出來的？是業務單位提的，還是IT自己抓的？

IT幫幫忙，一起把複雜的企業IT架構講清楚。

#備份 #RPO #RTO #資料保護 #災難復原 #企業IT #Presales